3.2.1.  Climate resilience data cubes

During the course of the pilot, the following datasets relevant to climate resilience were optimized and deployed at a data cube API demonstration end-point using the GNOSIS Map Server.

Table 2 — Datasets provided through GNOSIS Map Server data cube API

Figure 5 — ESA sentinel-2 Level-2A from COGs and STAC catalogs on AWS

Figure 6 — CMIP5 projections (air temperature) from Copernicus Climate Data Store

Figure 7 — ECMWF CEMS Fire Danger indices from Copernicus Climate Data Store

Figure 8 — Fuel Vegetation Types for Continental United States from landfire.gov

3.2.2.  Overview of supported OGC API standards to access the data

The GNOSIS Map Server implements several published and candidate OGC API standards and is a certified implementation of OGC API — Features as well as OGC API — Processes. This section describes some of these supported standards and illustrates their use with requests for the climate data collections listed above.

3.2.2.2.  OGC API — Coverages

The OGC API — Coverages candidate Standard is a simple API defining fundamental functionality to retrieve access data for arbitrary fields, area, time and resolution of interest from a data cube.

The main resource to retrieve data using the Coverages API is located at /collections/{collectionId}/coverage for each data collection. This resource supports a number of query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server:

Query parameter	Description	Requirements class
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Subsetting
bbox	For subsetting on spatial dimensions	Subsetting
datetime	For subsetting on temporal dimension	Subsetting
scale-factor	For resampling using the same factor for all dimensions (1: no resampling, 2: 2x downsampling)	Scaling (resampling)
scale-axes	For resampling using a specific factor for individual dimensions	Scaling (resampling)
scale-size	For resampling by specifying the expected number of cells for each dimension	Scaling (resampling)
width	For specifying the width of the output (resampling)	Scaling (resampling)
height	For specifying the height of the output (resampling)	Scaling (resampling)
properties	For selecting specific properties to return (range subsetting); deriving new fields using CQL2 expression	Range subsetting; Derived fields extension
filter	For filtering using a CQL2 expression	Range filtering extension
crs	For selecting an output coordinate reference system	CRS extension
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	CRS extension
subset-crs	For specifiying the coordinate reference system of the subset parameter	CRS extension

The Coverages draft currently also specifies a DomainSet JSON object which is linked using the [ogc-rel:coverage-domainset] link relation from the collection description, which may be included either within the collection description itself, or at a dedicated resource (/collections/{collectionId}/coverage/domainset). The schema for this DomainSet object describes the domain of the coverage (the extent and resolution of its dimensions / axes) and follows the Coverages Implementation Schema (CIS) 1.1.1. An example of such a domain set resource can be found at https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/coverage/domainset?f=json . At the time of writing this report, discussions are underway to potentially simplify the API by fully describing the domain directly within the collection description resource, using uniform additional dimensions, as well as the grid property, inside the extent property, which can describe both regular as well as irregular grids, removing the need for this extra resource. For example, see the collection description for the CMIP5 single pressure level data and its corresponding CIS domain set resource.

The Coverages draft currently also specifies a RangeType JSON object which is linked using the [ogc-rel:coverage-rangetype] link relation from the collection description, which may be included either within the collection description itself, or at a dedicated resource (/collections/{collectionId}/coverage/domainset). The schema for this RangeType object describes the range type of the coverage (the extent and resolution of its dimensions / axes) and follows the Coverages Implementation Schema (CIS) 1.1.1. An example of such a range type resource can be found at https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/coverage/rangetype?f=json . It might be possible to also describe the range type in a common way across the different OGC APIs using a JSON schema with semantic annotations, as per the work undertaken for OGC API — Features — Part 5: Schemas.

A Coverage Tiles requirements class is defined in OGC API — Coverages, leveraging the OGC API — Tiles standard while clarifying requirements for coverage tile responses. Example of coverage tiles requests are described below in the OGC API — Tiles section.

At the moment, the GNOSIS Map Server implementation of Coverages is limited to the following 2D (spatial dimensions) output formats:

• GeoTIFF (multiple fields, two-dimensional),

• PNG (single field, 16-bit output, currently using fixed scale (2.98) and offset (16384) modifiers).

There is a plan to add support for n-dimensional output formats, including netCDF, CIS JSON and eventually CoverageJSON as well. For coverages with more than two dimensions, a specific time and/or pressure slice must therefore be selected, currently requiring separate API requests to retrieve a range of time or pressure levels.

Some example of coverage requests:

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?f=geotiff=tas,tasmax,tasmin,pr,psl=Lat(-90:90),Lon(0:180)=400=2020-05-20 (GeoTIFF coverage with 5 bands for each field)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage?f=geotiff&subset=pressure(750) (GeoTIFF Coverage)

Figure 9 — Coverage request for CMIP5 maximum daily temperature

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?f=png=(tasmax-250)*400

3.2.2.3.  OGC API — Maps

The OGC API — Maps candidate Standard defines the ability to retrieve a visual representation of geospatial data. The main resource to retrieve data using the Maps API is located at /collections/{collectionId}/map for each data collection. This resource supports a number of query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server:

Query parameter	Description	Requirements class
bbox	For subsetting on spatial dimensions	Spatial Subsetting
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	Spatial Subsetting
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Spatial/Temporal/General Subsetting
subset-crs	For specifiying the coordinate reference system of the subset parameter	Spatial/Temporal/General Subsetting
datetime	For subsetting on temporal dimension	Temporal Subsetting
width	For specifying the width of the output (resampling)	Scaling (resampling)
height	For specifying the height of the output (resampling)	Scaling (resampling)
crs	For selecting an output coordinate reference system	CRS
bgcolor	For specifiying the color of the background	Background
transparent	For specifiying whether the background should be transparent	Background
filter	For filtering using a CQL2 expression	Filtering extension

Some example map requests:

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/map?width=2048=pressure(750)=0x002040

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/map?subset=pressure(850)=1024

NOTE:    Proper symbolization for this wind velocity map (above request) would require support for wind barbs. In the meantime, the Eastward and Northward velocity are assigned to the green and blue color channels.

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:temperature/map?subset=pressure(850)

Figure 10 — Sentinel-2 map (natural color)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-06-28

Some example map requests for a specific style, in conjunction with OGC API — Styles:

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/styles/precipitation/map?datetime=2022-09-04

Figure 11 — Sentinel-2 map for NDVI style

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-04-28

Figure 12 — Sentinel-2 map for Scene Classification Map style

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-06-28

A Map Tilesets requirements class is defined in OGC API — Maps, leveraging the OGC API — Tiles stand while clarifying requirements for map tile responses. Example of map tiles requests are described below in the OGC API — Tiles section.

3.2.2.4.  OGC API — Tiles

The OGC API — Tiles Standard defines the ability to retrieve geospatial data as tiles based on the OGC 2D Tile Matrix Set and Tileset Metadata Standard, originally defined as part of the Web Map Tile Service (WMTS) Standard. Unlike WMTS which focused strictly on pre-rendered or server-side rendered Map tiles, the Tiles API was designed to also enable the use of data tiles such as Coverages Tiles and Vector Tiles which can be styled, rendered and used for data analytics performed on the client side. Using pre-determined partitioning schemes facilitates caching for both servers and clients, resulting in more responsive dynamic maps.

The following Tiles API resources are defined:

Resource	Requirements Class	Description
…​/tiles	Tilesets list	List of available tilesets
…​/tiles/{tileMatrixSetId}	Tileset	Description of tileset and link to 2D Tile Matrix Set definition
…​/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}	Core	Tiles for a given Tile 2D Matrix Set, tile matrix/row/column

The GNOSIS Map Server supports a number of 2D Tile Matrix Sets for all of the collections it hosts, including:

• the GNOSIS Global Grid (EPSG:4326),

• WorldCRS84Quad (EPSG:CRS84 / EPSG:4326),

• WebMercatorQuad (EPSG:3857),

• WorldMercatorWGS84Quad (EPSG:3395),

• ISEA9R (ISEA),

3.2.2.4.1.  Coverage Tiles

The GNOSIS Map Server currently supports the following coverage tile formats:

• GNOSIS Map Tiles (multiple fields, n-dimensional)

• GeoTIFF (multiple fields, two-dimensional)

• PNG (single field, 16-bit value using fixed scale (2.98) and offset (16384) modifiers)

Support is planned for netCDF, CIS JSON, and eventually CoverageJSON as well as additional formats.

Example coverage tile queries:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288

To request a different sentinel-2 band than the default RGB (B04, B03, B02) bands:

Figure 13 — Sentinel-2 PNG coverage tile for band 08 (near infra-red)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=B08=png

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288?properties=B08

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage/tiles/WebMercatorQuad/1/1/0?f=geotiff=2022-09-04 (GeoTIFF coverage tile)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage/tiles/WorldCRS84Quad/0/0/0?f=geotiff=pressure(750) (GeoTIFF coverage tile)

3.2.2.4.2.  Map Tiles

The GNOSIS Map Server currently supports the following map tile formats:

• PNG (RGBA)

• JPEG

• GeoTIFF

• GNOSIS Map Tiles

Some example of map tiles queries:

Figure 14 — Sentinel-2 Level-2A map tile for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/ISEA9Diamonds/4/373/288

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/map/tiles/WorldCRS84Quad/0/0/0?subset=pressure(750)=0x002040

To get map tiles from a predefined style, in conjunction with OGC API — Styles:

Figure 15 — Sentinel-2 Level-2A map tile using Scene Classification Map style for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map/tiles/ISEA9Diamonds/4/373/288

Figure 16 — Sentinel-2 Level-2A map tile using NDVI style for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map/tiles/ISEA9Diamonds/4/373/288

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/styles/precipitation/map/tiles/WebMercatorQuad/1/1/0?datetime=2022-09-04

3.2.2.5.  OGC Common Query Language (CQL2)

The OGC Common Query Language, abbreviated CQL2, allows to define query expressions. Although introduced as a language to specify a boolean predicate for OGC API — Features — Part 3: Filtering, the language is easily extended for additional use cases such as filtering the range set of a coverage request, or to deriving new fields using expressions (that can return non-boolean values) including performing coverage band arithmetics, such as calculating vegetation indices.

Support for CQL2 in the filter parameter is implemented in the GNOSIS Map Server for Coverages, Features, Maps, Tiles as well as DGGS. For example, to request all data from the CMIP5 single pressure level collection where the maximum daily temperature is greater than 300 Kelvins, filter=tasmax>300 (unmatched cells will be replaced by NODATA values).

Support for CQL2 in the properties parameter is currently implemented for Coverages, Tiles and DGGS. For example, the pr precipitation property can be multiplied by a factor of one thousand using properties=pr*1000.

Using a CQL2 expression to filter out the clouds in a map tile:

Figure 17 — Sentinel-2 map tile filtered by Scene Classification Layer to remove clouds (a longer time interval with fewer clouds would be necessary to complete the mosaic)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/GNOSISGlobalGrid/3/4/17?filter=SCL<8 or SCL>10

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/ISEA9Diamonds/4/373/288?filter=SCL<8 or SCL>10

Using a CQL2 expression in coverage tile requests to perform band arithmetic computing NDVI:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)

Figure 18 — Coverage tile request from sentinel-2 computing NDVI

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)*10000=png

Using a CQL2 expression in a coverage request to multiply the relative humidity and filter resulting values below a threshold (20):

Figure 19 — Coverage request from relative humidity coverage multiplying r by 200 and returning only values where r > 20

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage?f=png=pressure(750),Lat(-90:90),Lon(0:180),time(%222023-04-03%22)=r*200=r%3E20

3.2.2.6.  OGC API — Discrete Global Grid Systems

The OGC API — DGGS candidate Standard allows to retrieve data and perform spatial queries based on hierarchical multi-resolution discrete grids covering the entirety of the Earth. There are three main requirements classes for this standard:

• Core (DGGS definition and zone information resource),

• Zone Data Retrieval (What is here?),

• Zones Query (Where is it?)

The following DGGS API resources are defined:

Resource	Requirements Class	Description
…​/dggs	Core	List of available DGGSs
…​/dggs/{dggsId}	Core	Description and link to definition of a specific DGGS
…​/dggs/{dggsId}/zones	Zone Query	For retrieving the list of zones matching a collection and/or query
…​/dggs/{dggsId}/zones/{zoneId}	Core	For retrieving information about a specific zone
…​/dggs/{dggsId}/zones/{zoneId}/data	Data Retrieval	For retrieving data for a specific zone

DGGS API requests imply the use a particular grid understood by both the client and the server, associated with the {dggsId} of the resource on which the request is performed. Several different discrete global grids have been defined. The GNOSIS Map Server currently supports two discrete global grids:

• the GNOSIS Global Grid, based on the 2D Tile Matrix Set of the same name defined in the EPSG:4326 geographic CRS, axis-aligned with latitude and longitude, and using variable width tile matrices to approach equal area (maximum variation is ~48% up to a very detailed zoom level),

• the ISEA9R (Icosahedral Snyder Equal Area aperture 9 Rhombus) grid, a dual DGGS of ISEA3H (aperture 3 hexagonal) for its even levels, using rhombuses/diamonds which, compared to hexagons, are much simpler to index and for which it is much easier to encode data in a rectilinear formats such as GeoTIFF. The area values of ISEA3H hexagons can be transported as points on the rhombus vertices for those ISEA3H even levels. The ISEA9R grid is also axis-aligned to a CRS defined by rotating and skewing the ISEA projection, also allowing to define a 2D Tile Matrix Set for it.

A client will normally opt to use OGC API — DGGS if it shares an understanding and internal use of the same grid with the server. Although for axis-aligned DGGS that can be represented as a 2D Tile Matrix Set OGC API — Tiles can be used to retrieve data for specific zones, the DGGS API enables zone data retrieval for other DGGS which are not axis-aligned or whose geometry makes that impossible (e.g., hexagons). Another important use of the DGGS API is the ability to efficiently retrieve the results of a spatial query (e.g., using CQL2) in the form of a compacted list of zone IDs.

3.2.2.6.1.  Core

The core requirements class defines requirements to list available DGGS, describe each of them and provide information for individual zones.

In the GNOSIS Map Server implementation of the zone information resource, since both supported DGGS also correspond to a 2D Tile Matrix Set, the Level, Row and Column for the equivalent OGC API — Tiles request is displayed on the information page, as can be seen below. For the DGGS {zoneId}, the level, row and column is encoded differently in a compact hexadecimal identifier. Some example zone information requests:

Figure 20 — GNOSIS Map Server information resource for GNOSIS Global Grid zone 5-24-6E

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/5-24-6E

Figure 21 — GNOSIS Map Server information resource for ISEA9Diamonds zone A7-0

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/A7-0

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/E7-FAE

3.2.2.6.2.  Zone Data Retrieval: What is here?

The Zone Data Retrieval requirements class allows to retrieve data for a specific DGGS zone. For axis-aligned DGGSs whose zone geometry can be described by a 2D Tile Matrix Set such as the GNOSISGlobalGrid, ISEA9R or rHealPix, this capability is equivalent to Coverage Tiles requests for the corresponding TileMatrixSets. This requirements class supports returning data for zones whose geometry is of an arbitrary shape e.g., hexagonal or triangular. The zone data retrieval resource is …​/dggs/{dggsId}/zones/{zoneId}/data, for which the GNOSIS Map Server supports a number of query parameters:

Query parameter	Description
filter	For filtering data within the response using a CQL2 expression
properties	For selecting specific properties to return (range subsetting); deriving new fields using CQL2 expression
datetime	For subsetting on temporal dimension
subset	For subsetting (trimming or slicing) on an arbitrary dimension (besides the DGGS dimensions)
subset-crs	For specifiying the coordinate reference system of the subset parameter
zone-depth	For specifying zone depths to return relative to the requested zone (0 corresponding to a single set of values for the zone itself)

Some example of data retrieval queries:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/3-4-11/data

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/E7-FAE/data

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones/0-0-3/data?f=geotiff=2023-04-03

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones/0-0-3/data?f=geotiff=2022-09-04

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/ISEA9Diamonds/zones/A7-0/data?f=geotiff=2023-04-03

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/ISEA9Diamonds/zones/A7-0/data?f=geotiff=2022-09-04

3.2.2.6.3.  Zone Queries: Where is it?

The Zone Query requirements class allows to efficiently retrieve the results of a spatial query in the form of compact list of zone IDs. The list can be compacted (the default) by replacing children zones by their parents when all children of that parent are part of the result set. The zone query resource is …​/dggs/{dggsId}/zones, for which the GNOSIS Map Server supports a number of query parameters:

Query parameter	Description
zone-level	For specifying the desired zone hierarchy level for the resulting list of zone IDs
compact-zones	For specifying whether to return a compact list of zones (defaults to true)
filter	For filtering using a CQL2 expression
datetime	For subsetting on temporal dimension
bbox	For subsetting on spatial dimensions
bbox-crs	For specifiying the coordinate reference system of the bbox parameter
subset	For subsetting (trimming or slicing) on an arbitrary dimension
subset-crs	For specifiying the coordinate reference system of the subset parameter

By creating a kind of mask at a specifically requested resolution level, DGGS Zones Query can potentially greatly help parallelization and orchestration of spatial queries combining multiple datasets across multiple services, allowing to perform early optimizations with lazy evaluation.

NOTE:    There are currently some limitations to the GNOSIS Map Server implementation of the Zones Query requirements class.

Examples of zone queries:

Where is relative humidity at 850 hPa greater than 80% on April 3rd, 2023? (at precision level of GNOSIS Global Grid level 6)

(using the default compact-zones=true where children zones are replaced by parent zone if all children zones are included)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=json (Plain Zone ID list output)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=uint64 (Binary 64-bit integer Zone IDs)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=geotiff (GeoTIFF output)

Figure 22 — GeoJSON output of a GNOSIS Global Grid DGGS Zone Query for relative humidity at 850 hPa greater than 80% on April 3rd, 2023

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=geojson

Where is maximum daily temperature greater than 300 degrees Kelvins on September 4, 2022? (at precision level of GNOSIS Global Grid level 6)

(using the default compact-zones=true where children zones are replaced by parent zone if all children zones are included)

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=json (Plain JSON Zone ID list output)

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=uint64 (Binary 64-bit integer Zone IDs)

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=geotiff (GeoTIFF output)

Figure 23 — GeoJSON output of a GNOSIS Global Grid DGGS Zone Query for maximum daily temperature greater than 300 degrees Kelvins on September 4, 2022

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=geojson

Additional examples of zone queries for a Digital Elevation Model (returning regions where elevation data is available):

https://maps.gnosis.earth/ogcapi/collections/SRTM_ViewFinderPanorama/dggs/ISEA9Diamonds/zones

https://maps.gnosis.earth/ogcapi/collections/SRTM_ViewFinderPanorama/dggs/ISEA9Diamonds/zones?f=json (as a list of compact JSON IDs)

4.2.1.  Data Sources

The Global Drought Observatory

The Global Drought Observatory (GDO), owned by the Copernicus Emergency Management Services, provides a global map of coarsely-gridded agricultural drought risk, along with a breakdown of the risk for each country. The drought risk is computed using the CDI, with the variables used to compute it and other drought-related variables provided in the user portal for download, but the CDI itself is not available for download and so is being calculated in the DSW.

Figure 27 — Global Drought Observatory Web Portal, https://edo.jrc.ec.europa.eu/gdo/php/index.php?id=2001

We obtain SMA and Fraction of Absorbed Photosynthetically Active Radiation (FAPAR) from the GDO data download service. These are provided as netCDF files and contain pre-computed anomalies, so can be assimilated directly into the back-end. The SMA uses a combination of the root soil moisture from the LISFLOOD model, the MODIS land surface temperature and the ESA Climate Change Initiative (CCI) skin soil moisture (https://hess.copernicus.org/articles/21/6329/2017/), and the FAPAR is from NASA optical imagery.

ERA5 Reanalysis from ECMWF CDS

The CDS portal provides an API interface to return either hourly or monthly averages of the ERA5 variables. Requesting the hourly data is necessary to compute anything which requires a frequency greater than monthly, which is the case for most drought indicators (e.g. SMA) which are in dekads. To ensure there is no anti-aliasing, the full 24hr dataset for each day of the month must be downloaded. This is very time-consuming and requests will fail if the number of data points exceeds the limit, which will occur for a period of 2 years or more, even for a single location.

There is a separate application, which can also be accessed via API, to return daily data. The CDS employs a queue management system, which determines the priority of each request based partially on the computational demand of the request. The daily data retrieval relies upon an underlying service to compute the daily statistics from the hourly data, demanding more resources than simply extracting the hourly or monthly data which are pre-computed. This means the request is held in the queue for a long time (up to hours), so there is no time benefit over using the hourly data. However, for a longer time-period which would be rejected if requested hourly, this provides a workaround. A further benefit of requesting daily, rather than hourly, data is that the downloaded file is smaller.

We compute SPI and SMA using variables from the CDS API. The SPI is computed from the total precipitation in monthly intervals. The SMA is computed from the soil water volume, which is available for 4 depth levels. The SMA for each depth is computed by calculating the z-score against a long term mean, using the same baseline time period as the SPI. The most relevant depth layer can then be selected by the user; for instance, a user interested in the health of crops with shallow roots may wish to access the surfacemost layer.

ERA5 Reanalysis from AWS

Input precipitation data was also tested using ERA5 data held within the Registry of Open Data on AWS versus the CDS API and found the Amazon Web Service (AWS) Simple Storage Service (S3) stored data could be accessed faster once virtual Zarrs has been setup, but there is a question over provenance as the data on AWS was put there by an organization other than the data originator and the Zarr approach didn’t work for more recent years as the S3 stored NetCDFs have chunking that is inconsistent. An issue was raised for the Python kerchunck library, to be able to cope with variable chunking, as this isn’t current supported. The issue has also been raised with the organisation storing the data on S3, and they are investigating.

NOAA API

The NOAA Climate Environmental Data Retrieval (EDR)

Safe Software extraction of climate forecast data

We reviewed the GeoJSON Feature point data extracted from the Climate scenario RPC4.5 downscaled for Canada provided by Safe Software. As a preliminary test of combining the reanalysis and forecast data the SPI was calculated using reanalysis data up until the end of 2022 and then forecast data for 2023 and 2024; see comparisons in Figure 28.

Figure 28 — Plot of the ECMWF precipitation and SPI, extended using the Canadian climate forecast data, compared to the GDO calculated SPI; generated using Copernicus Emergency Management Service information, Copernicus Climate Service and Canadian Centre for Climate Services data [2023]

4.2.2.  Further work

The work in this Pilot has focused on building this initial version of the workflow, deploying it via WPS and pulling data from different sources to understand the advantages and disadvantages of the different sources, including straightforwardness and speed of accessibility. For future Pilot activities we plan to continue to build the robustness of the approach, including testing and improving on the robustness of the interfaces to the input data sources and output provided to other Pilot components.

Other additions to the workflow which could support future collaboration with other OGC contributors include:

• The current work has focused on the extraction and generation of a point time-series, and so there are plans to expand the code to the extraction and generation of a 3D data cube. This might involve changing the output API interface to the OGC EDR API standard.

• The sources used to calculate the combined indicator currently includes only historical data. If Soil Moisture or FAPAR projections can be obtained, these could be combined with future predictions of precipitation from Safe Software and NOAA to project the CDI into the future.

• We currently focus on the CDI, a combination of precipitation, soil moisture and vegetation health data, which is most useful in agricultural contexts. Other combined indicators could be developed which are more applicable to other challenges; for instance, combining rainfall and temperature indicators may produce a drought warning more applicable to public health.

• The ECMWF Soil Moisture data contains information for multiple depths of soil. The service currently returns the moisture of just one of these layers, however, the most applicable layer will vary with location and crop type. For some use-cases, providing the option to choose the soil layer and providing guidance on how this can be done would be beneficial to the end user.

4.3.1.  Component Descriptions

D100 — Client instance: Analysis Ready Data Component

Our Analysis Ready Data component (ARD) uses the FME platform to consume regional climate model and EO data and generate FAIR datasets for downstream analysis and decision support.

The challenge to manage and mitigate the effects of climate change poses difficulties for spatial and temporal data integration. One of the biggest gaps to date has been the challenge of translating the outputs of global climate models into specific impacts at the local level. FME is ideally suited to help explore options for bridging this gap given its ability to read datasets produced by climate models such as NetCDF or OGC WCS and then filter, aggregate, interpolate and restructure it as needed. FME can inter-relate it with higher resolution local data, and then output it to whatever format or service is most appropriate for a given application domain or user community.

Our ARD component supports the consumption of climate model outputs such as NetCDF. It also has the capacity to consume earth observation (EO) data, and the base map datasets necessary for downstream workflows, though given time and resource constraints during this phase we did not pursue consumption of other data types besides climate data.

4.3.1.1.  ARD Workflow

The basic workflow for generating output from the FME ARD component is as follows. The component extracts, filters, interrelates and refines these datasets according to indicator requirements. After extraction, datasets are filtered by location and transformed to an appropriate resolution and CRS. Then the workflow resamples, simplifies and reprojects the data, and then defines record level feature identifiers, ECV values, metadata and other properties to satisfy the target ARD requirements. This workflow is somewhat similar to what was needed to evaluate disaster impacts in DP21. Time ranges for climate scenarios are significantly longer — years rather than weeks for floods.

Once the climate model, and other supporting datasets have been adequately extracted, prepared and integrated, the final step is to generate the data streams and datasets required by downstream components and clients. The FME platform is well suited to deliver data in formats as needed. This includes Geopackage format for offline use. For online access, other open standards data streams are available, such as GeoJSON, KML or GML, via WFS and OGC Features APIs and other open APIs. For this pilot we generated OGC Geopackage, GeoJSON, CSV and OGC Features API services.

Figure 29 — High level FME ARD workflow showing generation of climate scenario ARD and impacts from climate model, EO, IoT, infrastructure and base map inputs

As our understanding of end user requirements continues to evolve, this will necessitate changes in which data sources are selected and how they are refined, using a model based rapid prototyping approach. We anticipate that any operational system will need to support a growing range of climate change impacts and related domains. Tools and processes must be able to absorb and integrate new datasets into existing workflows with relative ease. As the pilot develops, data volumes increase, requiring scalability methods to maintain performance and avoid overloading downstream components. Cloud based processing near cloud data sources using OGC API web services supports data scaling. Regarding the FME platform, this involves deployment of FME workflows to FME Cloud. Note that in future phases, we are likely to test how cloud native datasets (COG, STAC, ZARR) and caching can be used to scale performance as data transactions and volume requirements increase.

It is worth underlining that our ARD component depends on the appropriate data sources in order to produce the appropriate decision ready data (DRI) for downstream components. Risk factors include being able to locate and access suitable climate models of sufficient quality, resolution and timeliness to support indicators as the requirements and business rules associated with them evolve. Any data gaps encountered are documented under this section under Challenges and Opportunities and in the common Lessons Learned chapter and the end of the ER.

Figure 30 — Environment Canada NetCDF GCM time series downscaled to Vancouver area. From: https://climate-change.canada.ca/climate-data/#/downscaled-data

Figure 31 — Data Cube to ARD: NetCDF to KML, Geopackage, GeoTIFF

Original Data workflow: - Split data cube - Set timestep parameters - Compute timestep stats by band - Compute time range stats by cell - Classify by cell value range - Convert grids to vector contours

Figure 32 — Extracted timestep grids: Monthly timesteps, period mean T, period max T

Figure 33 — Convert raster temperature grids into temperature contour areas by class

Figure 34 — Geopackage Vector Area Time Series: Max Yearly Temp

4.3.1.2.  ARD Development Observations

Figure 35 — FME Data Inspector: RCM NetCDF data cube for Manitoba temperature 2020-2099

Disaster Pilot 2021 laid a good foundation for exploring data cube extraction and conversion to ARD with using the FME data integration platform. A variety of approaches were explored for extraction, simplification and transformation including approaches to select, split, aggregate, and summarize time series. However, more experimentation was needed to generate ARD that can be queried to answer questions about climate trends. This evolution of ARD was one of the goals for this CRP. This goal includes better support for both basic queries, and analytics, statistical methods, simplification & publication methods, including cloud native — NetCDF to Geopackage, GeoJSON and OGC, APIs.

In consultation with other participants, we learned fairly early on in the pilot that our approach to temperature and precipitation contours or polygons inherited from our work in DP21 on flood contours involved too much data simplification to be useful. For example, contouring required grid classification into segments, such as 5 degree C or 10mm of precipitation etc. However, this effective loss of detail oversimplified the data to the point where it no longer held enough variation over local areas to be useful. In discussion with other participants, it was determined that simply converting multidimensional data cubes to vector time series point data served the purpose of simplifying the data structure for ease of access, but retained the ECV precision needed to support a wider range of data interpretations for indicator derivation. It also meant that as a data provider we did not need to anticipate or encode interpretation of indicator business rules into our data simplification process. By simply providing ECV data points, the end user was free to run queries to find locations and time steps where temp > or precipitation < some threshold of interest.

Initially it was thought that classification rules need to more closely model impacts of interest. For example, the business rules for a heat wave might use a temperature range and stat type as part of the classification process before conversion to vector. However, this imposes the burden of domain knowledge on the data provider rather than on the climate service end user who is much more likely to understand the domain they wish to apply the data to and how best to interpret it.

Modified ARD Data workflow:

1. Split data cube

2. Set timestep parameters

3. Compute timestep stats by band

4. Compute time range stats by cell

5. Convert grids to vector points”

Further scenario tests were explored, including comparison with historical norms. Calculations were made using the difference between projected climate variables and historical climate variables. These climate variable deltas may well serve as a useful starting point for climate change risk indicator development. They also serve as an approach for normalizing climate impacts when the absolute units are not the main focus. Interesting patterns emerged for the LA area that we ran this process on deltas between projected and historical precipitation. While summers are typically dry and winters are wet and prone to flash floods. Initial data exploration seemed to show an increase in drought patterns in the spring and fall. More analysis needs to be done to see if this is a general pattern or simply one that emerged from the climate scenario we ran. However, this is the type of trend that local planners and managers may benefit from having the ability to explore once they have better access to climate model scenario outputs along with the ability to query and analyze them.

Figure 36 — Modified ARD Workflow: NetCDF data cube to precipitation delta grids (future - historical) in Geopackage for LA

ARD Climate Variable Delta Data workflow:

1. Split data cubes from historic and future netcdf inputs

2. Set timestep parameters

3. Compute historic mean for 1950 — 1980 per month based on historic time series input

4. Multiply historic mean by -1

5. Use RasterMosaiker to sum all future grids with -1 * historic mean grid for that month

6. Normalize environmental variable difference by dividing by historic range for that month delta / (max — min)

7. Convert grids to vector contours

8. Define monthly environment variables from band and range values

More analysis needs to be done with higher resolution time steps — weekly and daily. At the outset monthly time steps were used to make it easier to prototype workflows. Daily time step computations will take significantly more processing time. Future pilots should explore ways of better supporting scalability of processing through automation and cloud computing approaches such as the use of cloud native formats (STAC, COG, ZARR etc).

4.4.1.  Component: Surface Reflectance ARD

• Inputs: Gaofen L1A data and Sentinel-2 L1C data

• Outputs: Surface Reflectance ARD

• What other component(s) can interact with the component: Any components requiring access to surface reflectance data

Surface Reflectance (SR) is the fraction of incoming solar radiation reflected from the Earth’s surface for specific incidents or viewing cases. It can be used to detect the distribution and change of ground objects by leveraging the derived spectral, geometric, and textural features. Since a large amount of optical EO data has been released to the public, ARD can facilitate interoperability through time and multi-source datasets. As the probably most widely applied ARD product type, the SR ARD can contribute to climate resilience research. For example, the SR-derived NDVI series can be applied to monitor wildfire recovery by analyzing vegetation index increases. Several SR datasets have been assessed as ARD by CEOS, like the prestigious Landsat Collection 2 Level 2, and Sentinel-2 L2A, while many other datasets are still provided at a low processing level.

WHU is developing a pre-processing framework for SR ARD generation. The framework supports radiometric calibration, geometric ratification, atmospheric correction, and cloud mask. To address the inconsistencies in observations from different platforms, including variations in band settings and viewing angles, we proposed a processing chain to produce harmonized ARD. This will enable us to generate SR ARD with consistent radiometric and geometric characteristics from multi-sensor data, resulting in improved temporal coverage. In the first stage of our mission, we are focusing on the harmonization of Chinese Gaofen data and Sentinel-2 data, as shown in Figure 37, the harmonization involves spatial co-registration, band conversion, and bidirectional reflectance distribution function (BRDF) correction. Figure 38 shows the Sentinel-2 data before and after pre-processing. Furthermore, we wish to seek the assessment of CEOS-ARD in our long-term plan.

Figure 37 — The processing chain to produce harmonized ARD.

Figure 38 — Sentinel-2 RBG composite (red Band4, green Band3, blue Band2), over Hubei, acquired on October 22, 2020. (a) corresponds to the reflectance at the top of the atmosphere (L1C product); (b) corresponds to the surface reflectance after pre-processing.

4.4.2.  Component: Drought Indicator

• Inputs: Climate data, including precipitation and temperature

• Outputs: Drought risk map derived from drought indicator

• What other component(s) can interact with the component: Any components requiring access to drought risk map through OGC API

• What OGC standards or formats does the component use and produce: OGC API — Processes

Drought is a disaster whose onset, end, and extent are difficult to detect. Original meteorological data, such as precipitation, can be obtained through satellites and radar, which can be used for drought monitoring. However, the accuracy is easily affected by detection instruments and terrain occlusion, and the ability to retrieve special shapes, such as solid precipitation, is limited. In addition, many meteorological monitoring stations on the ground can provide local raw meteorological observation data. The SPEI is a model to monitor, quantitatively analyze, and determine the spatiotemporal range of the occurrence of drought using meteorological observation data from various regions. It should supplement the result of drought monitoring with satellite and radar.

SPEI has two main characteristics: 1) it considers the deficits between precipitation and evapotranspiration comprehensively, that is, the balance of water; 2) multi-time scale characteristics. For 1) drought is caused by insufficient water resources. Precipitation can increase water, while evapotranspiration can reduce water. The differences between the two variables simultaneously and in space can characterize the balance of water. For 2), the deficits value of different usable water sources is distinct at different time scales due to the different evolution cycles of different types, resulting in various representations in temporal. By accumulating the difference between precipitation and evapotranspiration at different time scales, agricultural (soil moisture) droughts, hydrological (groundwater, streamflow, and reservoir) droughts, and other droughts can be distinguished by SPEI.

In our project, the dataset for SPEI calculation is ERA5-Land monthly averaged data from 1950 to the present. We selected years of data about partial areas of East Asia for experiments. Through the following flow of the SPEI calculation, we obtain the SPEI value for assessments of drought impact. The flow of the SPEI calculation is shown in Figure 39.

Figure 39 — Flow of the SPEI calculation.

WHU has provided the SPEI drought index calculation services through the OGC API — Processes, enabling interaction with other components. The current endpoint for OGC API — Processes is http://oge.whu.edu.cn/ogcapi/processes_api. This section will explain how to use this API for calculating the drought index.

• Example：/processes http://oge.whu.edu.cn/ogcapi/processes_api/processes The API endpoint for retrieving the processes list.

• Example：/processes/{processId} http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei The API endpoint for retrieving a process description (e.g. spei). This returns the description of “spei” process, which contains the inputs and outputs information.

• Example：/processes/{processId}/execution http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei/execution The API endpoint for executing the process. The spei process exclusively supports asynchronous execution, resulting in the creation of a job for processing. The request body:

{ “inputs”: { “startTime”: “2010-01-01”, “endTime”: “2020-01-01”, “timeScale”: 5, “extent”: { “bbox”: [73.95, 17.95, 135.05, 54.05], “crs”: “http://www.opengis.net/def/crs/OGC/1.3/CRS84” } } }

• Example：/processes/{processId}/jobs/{jobId} http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei/jobs/{jobId} The API endpoint for retrieving status of a job.

• Example：/processes/{processId}/jobs/{jobId}/results http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei/jobs/{jobId}/results The API endpoint for retrieving the results of a job, which are encoded as : [{ “value”: { “time”: “2000_02_01”, “url”: “http://oge.whu.edu.cn/api/oge-python/data/temp/9BC500C1B0E3438C090AF5C6F8602045/8d0357fb-8ffb-4e62-9c3a-55ad17a5831a/SPEI_2000_02_01.png” } }, …​…​ ]

Figure 40 — The SPEI results for the date 2000_02_01.

4.4.3.  Component: Data Cube Infrastructure

• Outputs: Results in the form of GeoTIFF after processing in Data Cubes

• What other component(s) can interact with the component: Any components requiring access to temperature and precipitation data, surface reflectance ARD, and drought risk map in part of Asia through OGC API

• What OGC standards or formats does the component use and produce: OGC API- Coverages, OGC API — Processes

WHU has introduced GeoCube as a cube infrastructure for the management and large-scale analysis of multi-source data. GeoCube leverages the latest generation of OGC standard service interfaces, including OGC API-Coverages, OGC API-Features, and OGC API-Processes, to offer services encompassing data discovery, access, and processing of diverse data sources. The UML model of the GeoCube is given in Figure 5, and it has four dimensions: product, spatial, temporal, and band. Product dimension specifies the thematic axis for the geospatial data cube using the product name (e.g. ERA5_Precipitation or OSM_Water), type (e.g. raster, vector, or tabular), processes, and instrument name. For example, the product dimension can describe optical image products by recording information on the instrument and band. Spatial dimension specifies the spatial axis for the geospatial data cube using the grid code, grid type, city name, and province name. The cube uses a spatial grid for tiling to enable data readiness in a high-performance form. Temporal dimension specifies the temporal axis for the geospatial data using the phenomenon time and result time. Band dimension describes the band attribute of the raster products according to the band name, polarization mode that is reserved for SAR images, and product-level band. The product-level band is the information that is extracted from the original bands. For example, the Standardized Precipitation Evapotranspiration Index (SPEI) band is a product-level band that takes into account the hydrological process and evaluates the degree of drought by calculating the balance of precipitation and evaporation.

Figure 41 — The UML model of WHU Data Cube.

WHU has organized ERA5 temperature and precipitation data, surface reflectance ARD, and drought risk map into cubes and offers climate data services through the OGC API — Coverages, and OGC API — Processes. The API endpoint of Processes has given in the previous chapter. The API endpoint of Coverages is http://oge.whu.edu.cn/ogcapi/coverages_api, allowing users to query and retrieve the desired data from the cube. This section provides examples demonstrating how to access the data from the cube using OGC API — Coverages.

• Example：/collections http://oge.whu.edu.cn/ogcapi/coverages_api/collections?bbox=112.65942,29.23223,115.06959,31.36234=10=2016-01-01T02:55:50Z/2018-01-01T02:55:50Z The API endpoint for querying datasets from the cube, and the query parameters including limit, bbox, and time.

• Example：/collections/{collectionId} http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602 The API endpoint for retrieving the description of the coverage with the specified ID from the cube.

• Example：/collections/{collectionId}/coverage http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602/coverage The API endpoint for retrieving the coverage in GeoTIFF format for the specified ID. Here is an example of the response:

Figure 42 — The coverage with the ID "2m_temperature_201602" in the Asian region.

• Example：/collections/{collectionId}/coverage/rangetype http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602/coverage/rangetype The API endpoint for accessing the range type of the coverage, which is part of the band dimension members in the cube. In this example, the coverage consists of only one band dimension member.

• Example：/collections/{collectionId}/coverage/domainset http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602/coverage/domainset The API endpoint for the domain set of the coverage, which is also the domain set of the cube.

4.5.1.  Climate Projection Data

To make climate projection data more easily usable we transformed CMIP5 data (version 1 of our project), now working on CMIP6, into an Analysis Ready Data collection of indices of future temperature and precipitation. Climate summaries for the contiguous 48 states were derived from data generated for the 4th National Climate Assessment. These data were accessed from the Scenarios for the National Climate Assessment website. The 30-year mean values for 4 time periods (historic, early-, mid-, and late-century) and two climate scenarios (RCP 4.5 and 8.5) were derived from the Localized Constructed Analogs (LOCA) downscaled climate model ensembles, processed by the Technical Support Unit at NOAA’s National Center for Environmental Information.

• Historical: 1976-2005

• Early-Century: 2016-2045

• Mid-Century: 2036-2065

• Late-Century: 2070-2099

In order to display the full range of projections from individual climate models for each period, data originally obtained from USGS THREDDS servers were accessed via the Regional Climate Center’s Applied Climate Information System (ACIS). This webservice facilitated processing of the raw data values to obtain the climate hazard metrics available in CMRA.

As LOCA was only generated for the contiguous 48 states (and the District of Columbia), alternatives were used for Alaska and Hawaii. In Alaska, the Bias Corrected Spatially Downscaled (BCSD) method was used. Data were accessed from USGS THREDDS servers. The same variables provided for LOCA were calculated from BCSD ensemble means. However, only RCP 8.5 was available. Minimum, maximum, and mean values for county and census tracts were calculated in the same way as above. For Hawaii, statistics for two summary geographies were accessed from the U.S. Climate Resilience Toolkit’s Climate Explorer: Northern Islands (Honolulu County, Kauaʻi County) and Southern Islands (Maui County, Hawai’i County).

This data is being updated to CMIP6 and will be available in the latter half of 2023. The system is being expanded globally using NASA NEX CMIP6 data using the same time periods and climate scenarios.

4.5.2.  Climate Indices

To provide a more approachable context to future climate, a collection of 47 indices of future temperature and precipitation are computed. These indices build upon prior work on Climdex indices and additional indices developed for National Climate Assessment 4 (NCA4).

• Cooling Degree Days: Cooling degree days (annual cumulative number of degrees by which the daily average temperature is greater than 65°F) [degree days (degF)]

• Consecutive Dry Days: Annual maximum number of consecutive dry days (days with total precipitation less than 0.01 inches)

• Consecutive Dry Days Jan Jul Aug: Summer maximum number of consecutive dry days (days with total precipitation less than 0.01 inches in June, July, and August)

• Consecutive Wet Days: Annual maximum number of consecutive wet days (days with total precipitation greater than or equal to 0.01 inches)

• First Freeze Day: Date of the first fall freeze (annual first occurrence of a minimum temperature at or below 32degF in the fall)

• Growing Degree Days: Growing degree days, base 50 (annual cumulative number of degrees by which the daily average temperature is greater than 50°F) [degree days (degF)]

• Growing Degree Days Modified: Modified growing degree days, base 50 (annual cumulative number of degrees by which the daily average temperature is greater than 50°F; before calculating the daily average temperatures, daily maximum temperatures above 86°F and daily minimum temperatures below 50°F are set to those values) [degree days (degF)]

• Growing-season: Length of the growing (frost-free) season (the number of days between the last occurrence of a minimum temperature at or below 32degF in the spring and the first occurrence of a minimum temperature at or below 32degF in the fall)

• Growing Season 28F: Length of the growing season, 28°F threshold (the number of days between the last occurrence of a minimum temperature at or below 28°F in the spring and the first occurrence of a minimum temperature at or below 28°F in the fall)

• Growing Season 41F: Length of the growing season, 41°F threshold (the number of days between the last occurrence of a minimum temperature at or below 41°F in the spring and the first occurrence of a minimum temperature at or below 41°F in the fall)

• Heating Degree Days: Heating degree days (annual cumulative number of degrees by which the daily average temperature is less than 65°F) [degree days (degF)]

• Last Freeze Day: Date of the last spring freeze (annual last occurrence of a minimum temperature at or below 32degF in the spring)

• Precip Above 99th pctl: Annual total precipitation for all days exceeding the 99th percentile, calculated with reference to 1976-2005 [inches]

• Precip Annual Total: Annual total precipitation [inches]

• Precip Days Above 99th pctl: Annual number of days with precipitation exceeding the 99th percentile, calculated with reference to 1976-2005 [inches]

• Precip 1in: Annual number of days with total precipitation greater than 1 inch

• Precip 2in: Annual number of days with total precipitation greater than 2 inches

• Precip 3in: Annual number of days with total precipitation greater than 3 inches

• Precip 4in: Annual number of days with total precipitation greater than 4 inches

• Precip Max 1 Day: Annual highest precipitation total for a single day [inches]

• Precip Max 5 Day: Annual highest precipitation total over a 5-day period [inches]

• Daily Avg Temperature: Daily average temperature [degF]

• Daily Max Temperature: Daily maximum temperature [degF]

• Temp Max Days Above 99th pctl: Annual number of days with maximum temperature greater than the 99th percentile, calculated with reference to 1976-2005

• Temp Max Days Below 1st pctl: Annual number of days with maximum temperature lower than the 1st percentile, calculated with reference to 1976-2005

• Days Above 100F: Annual number of days with a maximum temperature greater than 100degF

• Days Above 105F: Annual number of days with a maximum temperature greater than 105degF

• Days Above 110F: Annual number of days with a maximum temperature greater than 110degF

• Days Above 115F: Annual number of days with a maximum temperature greater than 115degF

• Temp Max 1 Day: Annual single highest maximum temperature [degF]

• Days Above 32F: Annual number of icing days (days with a maximum temperature less than 32degF)

• Temp Max 5 Day: Annual highest maximum temperature averaged over a 5-day period [degF]

• Days Above 86F: Annual number of days with a maximum temperature greater than 86degF

• Days Above 90F: Annual number of days with a maximum temperature greater than 90degF

• Days Above 95F: Annual number of days with a maximum temperature greater than 95degF

• Temp Min: Daily minimum temperature [degF]

• Temp Min Days Above 75F: Annual number of days with a minimum temperature greater than 75degF

• Temp Min Days Above 80F: Annual number of days with a minimum temperature greater than 80degF

• Temp Min Days Above 85F: Annual number of days with a minimum temperature greater than 85degF

• Temp Min Days Above 90F: Annual number of days with a minimum temperature greater than 90degF

• Temp Min Days Above 99th pctl: Annual number of days with minimum temperature greater than the 99th percentile, calculated with reference to 1976-2005

• Temp Min Days Below 1st pctl: Annual number of days with minimum temperature lower than the 1st percentile, calculated with reference to 1976-2005

• Temp Min Days Below 28F: Annual number of days with a minimum temperature less than 28degF

• Temp Min Max 5 Day: Annual highest minimum temperature averaged over a 5-day period [degF]

• Temp Min 1 Day: Annual single lowest minimum temperature [degF]

• Temp Min 32F: Annual number of frost days (days with a minimum temperature less than 32degF)

• Temp Min 5 Day: Annual lowest minimum temperature averaged over a 5-day period [degF]

The individual web services of climate indices and raster data for download can be accessed at: https://resilience.climate.gov/pages/climate-model-content-gallery

Or for each scenario:

• Historical: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-historical/about

• RCP 4.5 Early Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-4-5-early-century/about

• RCP 4.5 Mid Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-4-5-mid-century/explore?location=34.597533%2C-95.830000%2C5.00

• RCP 4.5 Late Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-4-5-late-century/about

• RCP 8.5 Early Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-8-5-early-century/about

• RCP 8.5 Mid Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-8-5-mid-century/about

• RCP 8.5 Late Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-8-5-late-century/explore?location=34.561983%2C-95.830000%2C5.00

The data can be viewed directly in the online map viewer or opened in ArcGIS Online, ArcGIS Desktop, or a StoryMap. To view in other softwares GeoService and KMZ URLs are on the right side of the page under View API Resources.

Figure 43 — View API Resources

4.5.3.  Summarized Indices for Locations

To support easier interpretation and local decision making, the above indices were summarized by county, census tract, and tribal areas using the Zonal Statistics as Table utility in ArcGIS Pro. The results were joined into the corresponding geography polygons. A minimum, maximum, and mean value for each variable was calculated. This process was repeated for each time range and scenario. Precomputing enables quick map and graph response in the web application, and also provides as easily reusable download for someone who wants to utilize the data elsewhere.

To reuse the summarized services outside of the CRMA application or to download the processed data visit the links below for the geography of interest.

• Counties: https://resilience.climate.gov/datasets/nationalclimate::climate-mapping-resilience-and-adaptation-cmra-climate-assessment-data/explore?layer=0=0.000000%2C0.000000%2C2.74

• Census Tracts: https://resilience.climate.gov/datasets/nationalclimate::climate-mapping-resilience-and-adaptation-cmra-climate-assessment-data/explore?layer=1=-0.000000%2C0.000000%2C2.76

• American Indian/Alaska Native/Native Hawaiian Areas: https://resilience.climate.gov/datasets/nationalclimate::climate-mapping-resilience-and-adaptation-cmra-climate-assessment-data/explore?layer=2=-0.000000%2C0.000000%2C2.71

On these pages, a list of buttons allow you to filter the selection to a subset by attribute or geography, download into a variety of formats, and translate the descriptive documentation for viewing in other languages.

4.5.4.  Future Work

For ESRI’s contribution, the first version of CRMA was well received, it is widely used by the intended users and there is high interest by many others. Before the first version was released we had requests for other countries, and customizations of the project.

Due to many customization requests version 2 is being developed from inception with the intent for all code, from data processing python to web application Javascript to be available in Github repositories with documentation of typical customization workflows.

• Use other climate projection data

• Compute other indices

• Summarize to other geographies

• Customize the web application

The project is not only a solution, but a pattern for others to adapt to their data, geography, goals.

Version 2 data development is underway and will include more indices, both imperial and metric units, and min/max/mean for statistics instead of only areal mean. We will update all modeling to to CMIP6, and expand from US to global. Anticipated release in Q4 2023.

5.1.1.  Technical Interoperability Experiments (TIE) Table

Below is a summarized list of the key datasets required to produce or update a wildfire hazard map.

• National fire database polygon data

• Fire Weather Index (FWI) daily maps

• Land cover maps

• Drought conditions

• Digital Elevation Model (DEM)

• Population density

• Fuel and vegetation data

Intact’s wildfire hazard map is developed exclusively for internal use. Aside from intellectual property terms, it is meant to be deployed in highly secured data environments, and as such it cannot readily interact with other components of the pilot at this point of time. The intent is to develop geospatial infrastructures and legal terms that would allow a closer collaboration with pilot’s participants.

Very early in the project, Intact also developed an H3 synthetic exposure dataset (see next figure) composed of 14M points spread out across the country in a statically representative pattern. The purpose of this dataset was to facilitate visualization and analysis of the exposure. It was also supposed to allow pilot participants to have a common exposure reference on which to develop decision-ready use cases for insurance, thus advancing towards standardization. Unfortunately, time constraints prevented update and sharing of this dataset.

Figure 45 — IFC’s exposure synthetic dataset, with Montreal – Ottawa corridor on the left, and close-up of Montreal on the right. Color scale represent relative risk density in each cell, while points are representative individual risks

5.2.1.  From Raw Data to ARD and Decision Ready Indicators

The United Nations Framework Convention on Climate Change (UNFCCC) is supported through a number of organizations providing key observation data related to climate change. Of primary interest to this project scenario is the Global Climate Observing System (GCOS) and Global Ocean Observing System (GOOS), and the Joint Working Group on Climate (WG Climate) of the Committee on Earth Observation Satellites (CEOS). In-situ data sources are provided through a number of program initiatives sponsored through NOAA and provide key indicators for climate change that cannot be directly inferred from raw satellite information.

GCOS defines 54 Essential Climate Variables of which 18 ECVs apply to the oceans domain. Of these, only 6 ECVs may be inferred from satellite based earth observations while the remainder must be inferred through in-situ site observations and/or sampling programs.

The following table identifies the ocean-specific ECVs and associated providers.

Table 3

As well, social and economic key indicators related to the area of interest are ingested to identify relationships between the immediate effects of climate change on the associated human activity.

Table 4

5.2.2.  Approach

Each ECV applicable to the use case is resolved as a service endpoint representing the area of interest, associated samplings and observations, and where possible inferred from earth observation datasets transformed as ‘analysis ready’. Earth observation datasets are sourced through the ESA GCOS service endpoint; Ocean related samplings and in-situ observations are sourced through NOAA; socio-economic data is sourced from various open data portals available through government agencies.

The project effort centers around 3 key challenges * the ability to collect data relevant to Climate Resilience; * the ability to apply the data in a coherent and standardized manner in which to draw out context; * and the ability to impart insight to community members and stakeholders so as to identify, anticipate and mitigate the effects of climate change across both local and international boundaries.

Each of these activities aligns with the best practices and standards of the OGC and are used as input to the MarineDWG MSDI reference model.

5.3.1.  Heat Impact DRI Component

This component takes the climate scenario summary ARD results from the ARD component and analyzes them to derive estimated heat impacts over time, based on selected climate scenarios. Central to this is the identification of key heat impact indicators required by decision makers and the business rules needed to drive them. Process steps include data aggregation and statistical analysis of maximum temperature spikes, taking into account the cumulative impacts of multiple high temperature days. Heat exhaustion effects are likely dependent on duration of heat spells, in addition to high maximum temperatures on certain days.

Figure 47 — ARD Query: Monthly Max Temp Contours

Figure 48 — ARD Query: Max Mean Monthly Temp > 25C

Figure 49 — Town of Lytton - location where entire town was devastated by fire during the heat wave of July 2021 - same location highlighted in ARD query from heat risk query in previous figure

5.3.2.  Drought Impact DRI Component

This component takes the climate scenario summary ARD results from the ARD component and analyzes them to derive estimated drought risk impacts over time based on selected climate scenarios. It also feeds drought related environmental factors to other pilot DRI components for more refined drought risk analysis. For the purposes of this pilot, it was recognised that more complex indicators such as drought are likely driven by multiple environmental and physical factors. As such, our initial goal was to select and provide primary climate variable data that would be useful for deriving drought risks in combination with other inputs. Given that the primary input to drought models is precipitation, or lack thereof, we developed a data flow that extracted total precipitation per month and made this available both as a time series CSV and GeoJSON datasets, as well as OGC API features time series points. This climate scenario primary drought data was provided for the province of Manitoba and for Los Angelas. These two regions were chosen since we had pilot participants interested in each of these regions and in the case of Manitoba there is also a tie in to future work as this is an area of interest for the subsequent Disaster Pilot 2023.

For the LA use case, we worked with Laubwerk to provide them with climate change impact data that could help drive a drought impact that could affect their future landscape visualization model. The idea is that based on changes to climatic variables, certain areas may be more or less suited to different vegetation types, causing the distribution of vegetation to change over time. For more on their component, please refer to section 7: From Data To Visualization.

In the case of this visualization component, simply providing precipitation totals per month were not sufficient to drive the needs of their vegetation model. In this case we did not have an intermediate drought model to feed climate variables to. In the absence of a more comprehensive drought model, we decided to develop a proxy drought risk indicator by normalizing the difference between future precipitation and past.

Calculations were made using the difference between time series grids of projected precipitation and historical grids of mean precipitation per month. These precipitation deltas were then divided by the historical max — mean per month to derive a precipitation index. The goal was to provide a value between -1 and +1 where 1 = 100% of past mean precipitation for that month. Naturally this approach can generate values that exceed the range of -1 to 1 if the projected precipitation values exceed the historic max or min. The goal was not so much to predict future absolute precipitation values but rather generate an estimated for precipitation trends given the influence of climate change. For example, this approach can help answer the question — in 30 years for a given location, compare to historical norms, by what percentage do we expect precipitation to increase or decrease. Laubwerk can then take these results and decide what degree of drought stress will cause a specific vegetation species to die out for a particular location.

Interesting patterns emerged for the LA area that we ran this process on deltas between projected and historical precipitation. While summers are typically dry and winters are wet and prone to flash floods. Initial data exploration seemed to show an increase in drought patterns in the spring and fall. More analysis needs to be done to see if this is a general pattern or simply one that emerged from the climate scenario we ran. However, this is the type of trend that local planners and managers may benefit from having the ability to explore once they have better access to climate model scenario outputs along with the ability to query and analyze them.

Figure 50 — FME Query Workflow: Geopackage precipitation delta time series to GeoJSON points

Figure 51 — FME Query Parameters: Geopackage precipitation delta time series to GeoJSON points

Figure 52 — FME Data Inspector: precipitation delta result showing potential drought risk for areas and times with significantly less precipitation than past

This approach is only a start and just scratches the surface in terms of what is possible for future drought projection based on climate model scenario ECVs. The specific business rules used to assess drought risk are still under development. FME provides a flexible data and business rule modeling framework. This means that as indicators and drought threshold rules are refined, it’s relatively straightforward to adjust the business rules in this component to refine our risk projections. Also, business rule parameters can be externalized as execution parameters so that end users can control key aspects of the scenario drought risk assessment without having to modify the published FME workflow. However one of the main goals of this pilot was not so much to produced highly refined forecast models for drought but rather to demonstrate the data value chain whereby raw climate model data cube outputs can feed a data pipeline that filters, refines, simplifies the data and ultimately can be used to drive indicators that help planners model visualize and understand the effects of climate change on the landscapes and environments within their communities.

To support future drought risk estimates for Manitoba, we also provided a precipitation forecast time series to Pixalytics as an input to their drought analytics and DRI component. Their component provides a much more sophisticated indicator of drought probability since in addition to precipitation it also takes into account soil moisture and vegetation. The goal was to extract precipitation totals per time step from the downscaled RCM — regional climate model ECV outputs for Manitoba based on CMIP5 (Coupled Model Intercomparison Project Phase 5) model results obtained from Environment Canada. For this use case the grids have a spatial resolution of roughly 10km and a temporal resolution a monthly time step. Pixalytics then ran their drought model based on these precipitation estimates in order to asses potential future drought risk in southern Manitoba. The data was provided to Pixalytics initially as a GeoJSON feed of 2d points derived from the data cube cells with precipitation totals per cell. We later also provided this same data feed as a OGC API Feature service.

For future phases of the climate or disaster pilots, it may be useful to explore additional approaches for both precipitation data analysis and combination with other related datasets and external models. It may be useful to segment cumulative rainfall below a certain threshold Pt within a certain time window (days, weeks or months), since cumulative rainfall over time will be crucial for computing water budgets by watershed or catch basin. To do this we would like to test the use of a higher resolution time step such as daily, to see if the increased resolution reveals patterns of interest that the coarser monthly time step does not. There are also other statistical RCM results that might be useful to make available (mean, min, max). Besides precipitation, climate models also generate soil moisture predictions which could used by this component to assess drought risk. This component would also benefit from integration with topography, DEMs and hydrology related data such as river networks, water bodies, aquifers and watershed boundaries. Therefore rather than just computing precipitation deltas at the cell level, it would likely be useful to sum precipitation by catch basin and compute future trends that may indicate potential drought or flood.

The specific business rules used to assess drought risk are still under development. FME provides a flexible data and business rule modeling framework. This means that as indicators and drought threshold rules are refined, it’s relatively straightforward to adjust the business rules in this component to refine our risk projections. Also, business rule parameters can be externalized as execution parameters so that end users can control key aspects of the scenario drought risk assessment without having to modify the published FME workflow.

It should be stressed that the field of drought modelling is not new and there are many drought modelling tools available that are far more sophisticated than anything described above. As such, subsequent Climate and Disaster pilots should explore how future climate projections can be funneled into these more mature climate models in an automated fashion to produce more refined estimates of projected drought risk. That said, we need to start somewhere, and it is hoped that this basic demonstration of the raw data to ARD to DRI value chain for drought can provide some insights into what type of indicators we may want to generate to help better understand future drought risks, and where we may want to improve on this process.

6.1.1.  Source Data

Our visualization ties data that is very global together with data that is hyper-local. That means we need to draw on data from a wide variety of sources that are not usually combined. Examples of data sources used for our visualization are:

• Satellite Imagery

• Building Footprints and Heights

• Plant Inventory from Bureau of Street Services and Department of Recreation and Parks

• Results from Climate Models, particularly RPC 4.5 data that was pre-processed for this purpuse by Safe Software as part of their work for this pilot (see the Safe Software ARD component in this document for more details)

• 3D Plant Models from the Laubwerk database

• Plant Metadata to Judge Climate Change Impact on Specific Species through given Environmental factors, also from the Laubwerk database

• Information on local mitigation measures from various sources

6.1.2.  Results

The aforementioned data sources were combined to create a detailed visualization of the area in question. The pairs of images below show a visualization of the status quo as first image and then a composite of the four scenarios we visualized (one scenario per vertical stripe). The scenarios are projections of possible climate scenarios with and without mitigation measures in place and are in the following order:

1. Year 2045 without any mitigation measures. Plants that were likely to die off due to adverse climate events were just removed based on a probability.

2. Year 2070 without any mitigation measures with plants removed like in the scenario before.

3. Year 2045 with mitigation measures. Plants that were just removed in the two scenarios before have been replaced by plants that are more resilient and are part of the aforementioned initiatives for better climate resilience.

4. Year 2070 with mitigation measures with the same replacement logic as in the scenario before.

It should be stressed that these are visualizations of possible outcomes, but there are are many factors that make hard to make exact predictions! This contribution is merely meant as an example of how data could be used to drive scenario-based hyper-local visualization.

Figure 53 — Overview of the Visualized Region (Status Quo)

Figure 54 — Overview of the Visualized Region (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section

Figure 55 — Above the Corner Sunset Blvd and N Curson Ave Looking North-East (Status Quo)

Figure 56 — Above the Corner Sunset Blvd and N Curson Ave Looking North-East (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section)

Figure 57 — Corner Franklin Ave And N Sierra Bonita Ave Looking East (Status Quo)

Figure 58 — Corner Franklin Ave And N Sierra Bonita Ave Looking East (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section)

Figure 59 — Corner Hollywood Blvd And Camino Palmero St Looking Looking North (Status Quo)

Figure 60 — Corner Hollywood Blvd And Camino Palmero St Looking Looking North (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section)

6.1.3.  Challenges and Learnings

The goal of a visualization like we did is to make data and its implications visible on a hyper-local level. The hope behind this is to turn a large amount of abstract data into something the general public can better judge the very local impact of global changes.

This hyper-locality brings to light a number of problems with the granularity, availability, and machine readability of existing data. Relating to our specific inputs, this means:

• Producing a high fidelity photorealistic 3D model of a specific area is still not easy. Even in an urban area of an industrialized country like we picked (which usually have better data availability), we had to resort to relatively simple elevation data and building footprints. There are solutions for this on the horizon, but general availability is not a given, yet. 3D models based on photogrammetry seem like a promising approach to reach higher fidelity where available, but that generally available datasets like these currently lack classification, so we would not be able to remove and replace vegetation elements. This will probably improve and become more widely available in the near future.

• Information about existing vegetation is of varying quality and completeness. Detailed data is sometimes maintained by different authorities with different scopes. In our case we used data from the Bureau of Street Services as well as the Department of Recreation and Parks. Those datasets have different data layout, different depth and quality of data. OpenStreetMap also sometimes has vegetation data, but coverage and data quality is also problematic. None of the aforementioned really cover individual plants on private property or unmanaged land, which we had to fill in from photogrammetry, satellite imagery, and aerial photography.

• Climate projection data is pretty widely available and generally easy to process in terms of data volume, because the areas a visualization will typically cover is pretty small compared to the resolution of most climate models. What is still a challenge is to turn climate scenario data into properties that are needed to easily model the impact on vegetation, like the probability of extreme drought, heat, or fire events. This was partially addressed by other contributions to this pilot and we expect it to see further improvements.

• Exact data on average plant behavior in the context of relevant climate indicators is extremely patchy. Most data is only qualitatively in nature. Data gathering is complex because of the large number of factors at play when judging health of plants. This is a complex researach topic that will need more work, both to produce more reliable projections based on existing research, but also on how to gather data about or predict plant health more reliably on a large scale.

• Information about climate change mitigation is often not present in a machine readable format. In our specific case, we gathered information manually from publicly available material, mostly websites. Part of the problem here is that several stakeholders are working on mitigation measures, from different local government organizations, over non-profit organizations, to private companies. Examples relevant to our specific example are City Plants (a non-profit supported by Los Angeles Department of Water and Power) and the County of Los Angeles Parkway Trees Program. This manual way of data gathering obviously will not scale, is prone to data being missed, and has no unified format. All of this makes automated processing next to impossible at the moment.

• There may be further factors that need to be considered, which are not part of any of the existing data sources. In this specific case we have the pretty high average age and also various pests and diseases that the Mexican fan palm (Washingtonia robusta), which has become such a distinctive feature of Southern California, especially Los Angeles, is suffering from. While this isn’t directly related to climate change, it still needs to be considered for any visualization to be accurate.

As was expected, the data-driven visualization of very local phenomena and changes is a challenging problem which surfaces lots of issues in terms of data availability as well as standardization and compatibility of storage formats.

7.4.1.  Climate Impact Chain

In the current workshop design of the vulnerability workshops of alpS, local climate impacts are assessed on a matrix. The responses from workshop participants highlighted the importance of clear, unambiguous, and simple language when communicating climate impacts. Inspired by the responses of the workshop participants, the wording of climate impacts was optimized and broken down in the context of an impact chain from climatic effect to direct and indirect climate impacts (Figure 3). Thus, it is easy to understand which climatic effects drive climate impacts. This facilitates the data-driven assessment of the exposure of individual communities. In addition to the exemplary impact chain for the forestry sector shown in figure 3, further impact chains were created for all relevant fields of action in climate adaptation.

Figure 80 — Climate impact chain for the forestry sector

7.4.2.  Uncontrolled external influences

Conducting a vulnerability assessment workshop as part of the adaptation process is a complex sub-process. Its success depends on many factors, some of which are controlled by the moderator, but others are not. The latter are here called “external factors” and encompass influences and motivations of individual participants. The identification of the relevant external factors is important because if the existence and markedness of external factors for a particular workshop is known, adequate predefined responses can be implemented to better control the sub-process.

Indeed, the question of what motivates climate change adaptation behavior is widely discussed in literature. In a meta-analysis over 106 studies van Valkengoed, A., & Steg, L. (2019) investigate the relationship between adaptation behavior of households and 13 motivational factors. These factors are included in various theoretical frameworks but are rather generalized and not concrete enough to be taken into account here. In fact, anything that influences the workshop participants can have an impact on the workshop outcome and could therefore be called a factor. However, in order to keep the application of the guideline practicable, the catalog of external factors is limited to the key factors, which in addition should also be easy to research and observe.

The evaluation of the existence and markedness of external factors on the basis of the compiled catalog needs to be performed from the participants’ perspective: How strongly do they perceive (consciously or subconsciously) an external influence. And does this external influence meet with an optimistic or pessimistic basic attitude? Are the participants rather jaded or thin-skinned?

We have learned that it is a good possibility to gather information about the background and motivation of individual participants in preparatory talks with the organizer.

Catalog of external factors:

1. Natural space the municipality / company is located in

2. Number of inhabitants / number of employees

3. Vulnerabilities are known that are affected by climate change

   1. strong dependence on a few infrastructures

   2. strong dependence on a few companies / sectors of the economy

   3. demographic characteristics

   4. shortages in emergency responses

4. The municipality / company depends on its neighbors to carry out its adaptation measures (e.g. upstream/downstream riparian community set of problems).

5. In case of a suffered catastrophe (here or elsewhere): Have neglected precautions led to legal or political consequences ?

6. The municipality / company has experience with weather extremes or unusual seasonal conditions.

7. The municipality / company is affected by other geophysical, geopolitical, social or economic crises.

8. The handling of climate change in the media is present.

9. Political backing is given.

10. Provided human resources are sufficient.

11. Monetary commitment for climate adaptation is sufficient.

12. Participants are legally obligated to take precautions.

13. Risks of increased devaluation of real estate, equity investments, property, plant and equipment as well as increased depreciation, interest and insurance costs exist.

14. Participants recognize different needs, advantages and benefits.

15. Individuals are willing to take responsibility.

16. Different perception of the environment: outdoor professionals (e.g. farmers, foresters) as well as indoor professionals are participating.

17. Different levels of knowledge: accepted experts for individual topics (e.g. infrastructure, public health) are participating.

8.1.1.  Case study 1: Visualization for drought indicator

On the fundament of SPEI and OGE, we visualize the drought risk map on a virtual globe, as given in Figure 82 (a). The color matching of the visualization result is referred to the classification standard for the drought grade of SPEI illustrated in Table 1. The red and orange area in the visualization result represents a trend of drought (SPEI≤-0.5), while the green and blue represent wetness. The SPEI is calculated for each month of the input dataset, and users can visualize the SPEI of any month on the virtual globe for flexible drought analysis. Meanwhile, the use case also supports cubes-based SPEI visualization for time series drought analysis as given in Figure 82 (b), where the height of the cube is a range of time arranged in order of month, and each layer in the cube represents drought impact of one month.

Figure 82 — Visualization of SPEI on a virtual globe.

8.1.2.  Case study 2: Drought Risk analysis of Yangtze River basin

In the summer of 2022, an extreme drought hit the Yangtze River basin, posing huge impacts on agriculture, the ecosystem, and human livelihoods. It developed rapidly in the upper, middle, and lower reaches of the Yangtze River, intensifying on a large scale in 10 provinces (municipalities) in the basin (https://doi.org/10.1002/rvr2.23). The water area of Poyang Lake has been reduced by 90%, threatening the habitat for fish and migratory birds, etc. To analyze drought trends in the Yangtze River Basin, we visualized monthly SPEI for 2022, as shown in Figure 83. From the Figure, it can be seen that the drought index in the Yangtze River Basin has been rising since March. In July, the drought risk map turned light yellow, indicating a moderate drought. In August and September, the drought further intensified and reached an extreme drought situation. In October, the drought eased somewhat, and it had subsided mainly by November.

Figure 83 — Drought risk map in part of China.

8.1.3.  Case study 3: Drought risk analysis of Poyang Lake

Due to the extreme drought in the Yangtze River Basin, the water inflow into Poyang Lake, the largest freshwater lake in China, declined dramatically due to continuous hot weather with little rain since early summer. Hence, we developed a use case of drought analysis applying multi-source SR ARD.

In this use case, we collected Sentinel-2 SR and Landsat-8 SR, and produced Gaofen-1 WFV SR data in the center area of Poyang Lake (As shown in Figure 84) before and during the drought period. NDWI indices were calculated to monitor water area changes in Poyang Lake. Water bodies typically exhibit positive NDWI values, making it an effortless method to extract water areas. As illustrated in Figure 85, the first column represents Poyang Lake before the drought, while the last three columns represent Poyang Lake which was currently experiencing the drought. It is evident from the RGB composite that the water body of Poyang Lake has significantly decreased due to the drought weather. The water body extraction results by NDWI indicate that from May to October, the water area in the study area decreased from ~1800 square kilometers to ~350 square kilometers, representing a reduction of ~ 80% in water area.

Figure 84 — The study area of the Poyang Lake case.

Figure 85 — The changes in Poyang Lake before and during the drought period.

8.2.1.  Background

Definition of Analysis Ready Data (ARD) (defined by CEOS):

Analysis Ready Data (ARD) is remote sensing data and products that have been pre-processed and organized to allow immediate analysis with little additional user effort and interoperability both through time and with other datasets.

Major steps in preparing satellite data into ARD include conversion of raw reading into radiometric quantity, quality assessment, quantity normalization, and temporal integration. The ARD should follow the FAIR (Findable, Accessible, Interoperable, and Reusable) Data Principles.

Immediate analysis requires that data obtained by the data users exactly matches users’ specification in the format, projection, spatial/temporal coverage and resolution, and parameters so that it can be ingested into user’s analysis system immediately without further efforts. Since individual data users and projects have different requirements personalized services for customizing the data must be provided in order to meet the requirement of immediate analysis, which we call ARD services.

Essential Climate Variables (ECV) are key data sets for climate change studies. ECV Inventory houses information on Climate Data Records (CDR) provided mostly by CEOS and CGMS member agencies. The inventory is a structured repository for the characteristics of two types of GCOS ECV CDRs:

• Climate data records that exist and are accessible, including frequently updated interim CDRs

• Climate data records that are planned to be delivered.

The ECV Inventory is an open resource to explore existing and planned data records from space agency sponsored activities and provides a unique source of information on CDRs available internationally. Access links to the data are provided within the inventory, alongside details of the data’s provenance, integrity and application to climate monitoring.

The client is used the existing CEOS WGISS Community Portal. The portal is capable of providing automated discovery and customization services of ECV and satellite data. The client will be able to discover and access ECV and other remote sensing data and customize them into ARD for anywhere in the world to support various climate change resilience analysis.

8.2.2.  Approach

The client instance is implemented as a Web application to support the creation and delivery of ARD for climate change impact assessment.

The Carbon Portal conducted data discovery and access in two steps:

• step 1: Data collection search

• step 2: Granule search to search granules in the collection

ARD services are enabled on results of granule search if the collection is an ECV. If the ECV data provider has implemented the WCS service for the dataset, the portal will directly communicate with ECV provider’s WCS server for ARD service. If the ECV data provider does not have the WCS service, the portal’s server will download entire granule and stage it on the portal server to provide ARD service.

Most of ECV data provides don’t provide such service.

Figure <[software-architecture]> shows a software architecture of the CEOS WGISS Carbon Community Portal.

Figure 86 — Software Architecture

ECV Inventory v4.1 records are converted as a unified form of the portal predefined metadata format by a converting tool. Retrieve collection metadata for ECV entries from CWIC/FedEO OpenSearch referred by Data Record Information. There is 1251 ECV inventory records (Same as WGClimate, 870 for Existing, 381 for Planned). The portal supports totally 1910 predefined ECV relative collection datasets from ECV Records.

ARD service for ECVs in case that providers have no WCS services:

• Support when user select one granule entry

• Download granule dataset file from given repository, and manipulate it for serving WCS

• Stage the data in portal backend server and generate a list of all coverages in the granule

• User specifies the specifications of data to download

• User obtains the customized data by downloading via WCS GetCoverage request

ARD service for ECVs with data providers’ WCS:

• Directly talk to provider’s WCS

• Without granule downloading and stage steps in the portal’s backend server.

8.2.3.  Use Case: The climate change impact on crop production in Turkmenistan

The use case of the climate change impact on crop production in Turkmenistan. However, the portal can switch to another use case or support multiple use cases if this pilot requests us to do so.

Drought is one of the major climate-related natural hazards that cause significant crop production loss in Turkmenistan. Climate change increases the risk of drought in Turkmenistan. Crop models (such as WOFOST) are often used to support the decision-making in long-term adaptation and mitigation. The client will be used to prepare data to be readily used as parameters and drivers in such modeling processes. Drought impact analysis data may include long time series of precipitation, temperature, or indices for crop conditions, water content, or evapotranspiration. Many of these climate data and products from satellite sensors are served at NASA’s Goddard Earth Sciences Data and Information Services Center, such as GPM data products, MERRA assimilated climate data. These will be used in the case of drought impact assessment in Turkmenistan.

The drought impact ARD case will demonstrate:

1. Applicability of open standards and specifications in support of data discovery, data integration, data transformation, data processing, data dissemination and data visualization

2. Transparency of metadata, data quality and provenance

3. Efficiency of using ARD in modeling and analysis

4. Interoperable dissemination of ARD abiding by FAIR principles

The searching is starting with the following information:

• Keyword: surface soil moisture

• Filter: daily

• Date: 10/1/2021, 10/1/2020, 10/1/2019, 10/1/2018

• Area: Turkmenistan (Bbox: 52.264(Left), 35.129(Bottom), 66.69(Right), 42.8(Top))

Choose a collection dataset:

Groundwater and Soil Moisture Conditions from GRACE and GRACE-FO Data Assimilation L4 7-days 0.25 x 0.25 degree Global V3.0 (GRACEDADM_CLSM025GL_7D) at GES DISC

Choose the following granule data file:

GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20220926.030.nc4 (for year 2022)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20210927.030.nc4 (for year 2021)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20200928.030.nc4 (for year 2020)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20190930.030.nc4 (for year 2019)

Retreve the file and choose a variable:

sfsm_inst (Surface soil moisture percentile)

Adjust legend color (0 is the least soil moisture), and get the following results:

Figure 87 — Surface soil moisture percentile (year 2019-2022)

8.5.1.  Ocean Acidification & Food Security

The ocean is responsible for upwards of 30% of the absorption of carbon dioxide from the atmosphere. As CO₂ is taken in, it combines with the water to form carbonic acid causing the pH to lower. As concentrations of CO₂ in the atmosphere continue to increase, the pH of the ocean has fallen by as much a 0.1 pH units — representing a 30% increase in ocean acidity. As acidity rises, available carbonate ions bond with excess hydrogen ions, impeding the development of calcifying organisms such as oysters and shellfish. Of critical importance is the recognition that, as ocean acidity increases, the ability of the ocean to effectively act as a carbon sink for atmospheric CO₂ is directly reduced further spiralling the future impact of anthropogenic activities and CO₂ emissions.

This use case attempts to relate the trends in changing climate variables to the ocean’s ability to support the shellfish aquaculture industry along the North-East coastline of the United States. Of particular importance is the direct relationship between essential climate variables and the carrying capacity of coastal environments to support dependent socio-economic activities. Indirectly this use case attempts to identify the role of coastal ecosystems within a nature-based climate resilience strategy.

8.5.2.  Background

The study combines publicly available socio-economic data with climate change indicators relevant to an area of interest off the coast of Maine USA. This area is supported through a number of observation platforms to measure ocean surface temperatures, salinity, wave heights and other important characteristics related to the ocean’s state. Raw data processed to ARD provide additional metrics of the ocean’s regional climate indicators.

The framework takes advantage of previous efforts made through the OGC MarineDWG implementing a ‘federated marine spatial data infrastructure’ (FMSDI). In this case, the framework is designed to incorporate each data source as an independent service endpoint encoded as an OGC-compliant implementation of Feature, Coverage and/or Observation Collection. The service endpoints are developed and aligned with the OGC Features API, OGC EDR API and the OGC Observations, Measurements & Sampling (OMSv3) standards respectively. The goal being to take advantage of these standards and specifications as an adapter to the custom encoding of each raw data source allowing for a predictable semantic relationship and a loosely-coupled distributed feature schema.

This use case extends the concept of Analysis Ready Data to include processed data pipelines sourced from in-situ observation collections and sampling programs. Raw data, such as NetCDF datasets provided through the NOAA Saildrone program for monitoring ocean conditions, are processed into an ‘ARD’ encoded using the OGC Moving Features specification, mf-json. Extending the concept of ARD to include datasets sourced from non-satellite based observing platforms allows for a consistent view of important datasets independent of their originating platforms and associated processes and procedures. Where possible, this use case applies the OGC OMSv3 concepts of Host, Observation and Observable collections over a common spatio-temporal coverage area to reduce raw data measurements to analysis ready data.

The use case is modelled as a federated service employing a recognized schema compliant with OGC and/or external industry standards. A user query resolves each ECV to its source and combines the related feature and observation data into a ‘decision ready dataset’ for further exploration.

Example — Storyline

In this use case, site information available through the Maine open data portal is used to define an area of interest. Related socio-economic variables for the area of interest and the topic are resolved against the state government’s open data portal (GDP, employment metrics, etc.). The area of interest is used to refine the ARD datasets applicable to the area and associated ECV measurements across the time period of interest are processed and aggregated using a weighted average approach. The net result is an indicator of the relationship between the set of ECV measurements as a trend with milestones representing the harvest yields for each defined time period.

8.5.3.  Challenges, Resolutions & Lessons Learned

• Spatial Resolution

• Temporal Resolution

• Pub/Sub Event Model

• Provenance [ accuracy, reliability, peer-review, …​]

• Map, Binning and Global Grids

• Weighted relationships between observable properties and features of interest

8.5.4.  Future Work

Catalog Services When combining EO observation datasets with in-situ observations and sampling programs, an inordinant amount of effort is required to find acceptable sources of ARD datasets. Although individual organizations tend to align with the ISO 19115 metadata standard for describing ARD datasets, there is limited support apart from manual efforts to discover aligned ARD datasets provided across multiple providers. Recently, the OGC announced an effort to establish the GeoDCAT working group. This effort, combined with efforts aligned with the OGC OMS SWG, would be beneficial if the goal is to address the requirement to harvest metadata across multiple providers in one ‘centralized’ service endpoint.

Temporal Resolution Typically when addressing spatial analysis, the temporal resolution of the datasets is assumed to be aligned. In the case of climate modelling and raw EO datasets, care must be taken to ensure the temporal resolution of the ARD aligns with the temporal dimension of in-situ observations, sampling programs, and real-world feature datasets.

Scalability Considering the volume of data to describe climate trends specific to an area of interest, the methodology of how raw data through to ARD is loaded into a client environment needs to be addressed. The integration framework in support of the above use case tends to instantiate local copies of raw data and ARD datasets into the compute environment for processing and analysis. The OGC GeoDatacube initiative is well positioned to play a role in addressing the scalability requirements although it’s unclear whether this approach addresses a loosely coupled, distributed data pipelines or requires local cacheing of datasets within the GDC processing workflow.